All DatabasesMacTech Vol 09-1993
Aliases
Volume Number: 9
Issue Number: 1
Column Tag: Cover Story
Related Info: Alias Manager Event Manager
Aliases ’R us
Or, how to make the System do the grunt work.
By Tim Swihart, Cupertino, California
Note: Source code files accompanying this article are located on MacTech CD-ROM
or source code disks.
About the author
Tim Swihart is an accomplished author and programmer. He is the author of
numerous programming articles and the co-author of “Programming for System 7”
(the first source code-oriented System 7 book not written by Apple, part of
Addison-Wesley’s “Macintosh Inside Out” series). Tim is also the author of BNDL
Banger - believed to be the first publicly available solution for the hassles of getting
the Finder to recognize BNDL-related resource changes.
Aliases are a great part of System 7 - they provide a compact, portable
“pointer” to files, folders, and even other volumes. Aliases remember where their
target is, even if that target is offline, unmounted, renamed, or restored from a
backup.
Aliases are generally transparent to most applications (the Finder and Standard
File conspire to hide them from your application). But, perhaps your application can
offer users additional functionality by taking further advantage of the flexibility
aliases offer. They’re an easy way to keep track of ancillary files that your application
needs, but that maybe don’t have to be in either the Preferences folder or in the same
folder as your application. Inside Mac uses the example of a custom dictionary for a
specific document - aliases allow your application to tie the dictionary and the
document together, without requiring the user to keep them in the same place for all
eternity.
The paragraphs ahead show how to incorporate aliases within your own
application and along the way we’ll create an application (Alias Meister) that
simplifies creating and sorting Finder aliases. It’s rare that an application honestly
needs to create Finder aliases, but they provide an easy way to demonstrate the
concepts shown in this article. So we’ll examine one of those “rare” applications as
we forge ahead. Once you've learned the basics of creating and managing aliases, you'll
be better prepared for dealing with the Edition Manager (which uses aliases as the link
between an edition and the document that published it) and many other parts of the
System.
A Word About the Environment
Alias Meister was created under MPW C v.3.2.3 and all of the listings in the
article are designed to compile under MPW. A Think C v.5.0.3 compatible version of
this application is provided on the disk for this issue. There are minor differences
between the two versions, but the resulting applications are functionally equivalent.
A Word About Aliases
There are two common things that come to mind when talking about aliases. Most
users immediately think of Finder aliases, but they’re really just a special case of the
second type - a generic alias record. Each alias record uniquely identifies one file and
is traditionally stored as an ‘alis’ resource. Thus, a Finder alias is simply a small file
with one ‘alis’ resource, a special file type, and sometimes a custom icon family.
The custom icon is for the user's benefit and the special file type is for the
Finder’s benefit. That leaves with only the ‘alis’ resource, or rather, the alias record
- which is exactly what we want to focus on.
Why Use Aliases?
An alias record contains the target file’s ID number, name, parent folder ID,
volume type the target lives on (floppy, hard drive, server, etc.), creation date, file
and creator types, and, if needed, the information required to mount the volume the
target lives on (this is e specially important if the target is, or lives on, a shared
volume). This provides enough information for the Alias Manager to hunt down the
target file under most circumstances. There are times that the target simply can’t be
found because all of the information in an alias record has become out of date (backup a
file, delete it, restore it to a different location, and rename it - that pretty much
invalidates everything in the alias record). Under normal circumstances, aliases are
very robust and the Alias Manager will update an alias it’s using if that alias no longer
completely describes the target file (as would happen if the target was renamed).
For more information on the Alias Manager’s search algorithms, see “A Brief
Tangent” later in this article or read Chapter 4 of "Inside Macintosh: Files" from
Addison-Wesley. You’ll also find additional information in “Inside Macintosh: Files”
on updating “stale” aliases.
Despite the wealth of information kept in an alias record, its format (with two
minor exceptions) is considered off limits. Those two exceptions are the userType
field (which can also be used to hold any 4 bytes of information your application
desires) and the aliasSize field (which is simply a count of the number of bytes the
rest of the alias record occupies). The parent folder ID, volume mounting information,
creator type, and other bits of information that help uniquely identify the target are
all stashed in the undocumented, variable-length, chunk of data that makes up the bulk
of the alias record.
Since most of an alias record’s contents are off limits to applications, why bother
to use one? Why not just save an FSSpec record for the target? After all, the format
of an FSSpec record is clearly documented- it contains the volume reference number
that the target lives on, along with the target's parent folder, and the target’s file
name. What more could you ask for?
Stability! FSSpec records are “fragile” and are quickly rendered meaningless
between launches of your application. If the target file moves, is renamed, is on an
unmounted volume, or is simply on a volume that wasn’t mounted in the same order as
it was when the FSSpec was created (such as removable media), the FSSpec is no
longer accurate (if any of those three fields change, the FSSpec is “damaged” and
repairing it often isn’t possible. So, saving an FSSpec is of no real value.
Aliases, on the other hand, are designed to hold enough information that the target
file can be tracked down on demand, even if it’s on a floppy or server that’s not
currently online (the Alias Manager will prompt the user to insert the target floppy
or will mount the desired server) or if it’s been moved, renamed, or restored from a
backup (which tends to alter the file’s ID number).
Still not convinced? Are you sitting there grumbling that File Manager routines
don’t actually accept aliases, no matter how wonderful aliases are, so what’s the real
point of using them? The Alias Manager routine ResolveAlias easily converts an alias
record into an FSSpec (which is what the new System 7 File Manager routines like
best). The Alias Manager routine NewAlias converts an FSSpec into an alias record.
Together, they make it simple to have the best of both worlds - the flexibility of alias
records and the ease-of-use of FSSpec records.
Time For Some Examples
I use a lot of Finder aliases to help keep my productivity up - they let me jump
quickly from folder to folder, move files easily between any of the several Macs I use
(they all have File Sharing turned on and they all have a collection of aliases to my
other Macs), and they help clutter up my desktop (a clean desktop is a sign of too much
spare time). I use so many aliases, I’ve started sorting them into various locations -
the most heavily used aliases stay on the desktop, the least used are in a folder within
my Apple Menu Items folder, and the rest float loose in my Apple Menu Items folder.
Creating a new Finder alias involves several steps: selecting the item’s icon;
picking Make Alias from the Finder’s File menu; and moving the resulting alias to
where I want it (which is usually a folder that has be opened in yet another step).
Referenced by (106):